Currently, “information superhighway” and “multimedia” are probably the most often spoken and least often understood aspects of a coming revolution in data communication. Although issues specific to an information superhighway are beyond the scope of the present discussion, interactive multimedia systems are very much within the present scope.
An interactive multimedia system is broadly defined as a system capable of processing, storing, communicating and coordinating data pertaining to visual information, aural information and other information. Visual information is generally divided into still picture or graphics and full motion video or animation categories. In the vernacular of those involved in multimedia, such visual information is generically referred to as “video.” Aural information is generally divided into speech and non-speech categories and is generically referred to as “voice.” “Other information” is directed primarily to computer data, often organized in files and records, and perhaps constituting textual and graphical data. Such computer data are generally referred to as “data.”
To date, multimedia has, for the most part, been limited to stand-alone computer systems or computer systems linked together in a local area network (“LAN”). While such isolated systems have proven popular and entertaining, the true value of multimedia will become apparent only when multimedia-capable wide area networks (“WANs”) and protocol systems are developed, standardized and installed that permit truly interactive multimedia. Such multimedia systems will allow long distance communication of useful quantities of coordinated voice, video and data, providing, in effect, a multimedia extension to the voice-only services of the ubiquitous telephone network.
Defining the structure and operation of an interactive multimedia system is a critical first step in the development of such system. Accordingly, before entering into a discussion herein of more specific design issues, it is important to discuss more general questions that need to be resolved concerning design objectives of the system as a whole and some generally agreed-upon answers and specifications.
Interactive multimedia may be thought of as an electronic approximation of the paradigm of interactive group discussion. It involves the interactive exchange of voice, video and data between two or more people through an electronic medium in real time. Because of its interactive and real-time nature, there are some stringent requirements and required services not normally associated with multimedia retrieval systems. Some of the more obvious examples of those requirements and services include latency (transmission delay), conferencing, availability (“up-time”) and WAN interoperability.
The evolution of existing private branch exchange (“PBX”) and LAN topologies towards a composite interactive multimedia system based upon client-server architectures and isochronous networks is a natural trend. However, to merge the disparate mediums of voice, video and data successfully into a cohesive network requires that three fundamental integration issues be defined and resolved. The first of the fundamental integration issues is quality of service (“QoS”). QoS is defined as the effective communication bandwidth, services and media quality coupling of separate equipment or “terminals” together and the availability (“up-time”) of the same.
QoS parameters are divided into four groups: 1) terminal QoS, 2) network QoS, 3) system QoS and 4) availability requirements. Thus, QoS parameters must be defined for both terminal equipment (“TE”) and network equipment (“NE”) governing the communication of data between the TE. System QoS is derived from a combination of terminal and network QoS. The suggested values for QoS parameters are considered to be a practical compromise between required service quality, technology and cost. See, Multimedia Communications Forum (“MMCF”) Working Document “Architecture and Network QoS”, ARCH/QOS/94-001, Rev. 1.7, MMCF, (September 1994) and ITU-T Recommendation I.350 “General Aspects of Quality of Service and Network Performance in Digital Networks, including Integrated Services Digital Networks (“ISDNs”), (1993). The following Table I summarizes some suggested parameters for terminal QoS.
TABLE ITerminal QoS ParametersParameterParameter TypeParameter ValueExplanationAudio Frequency3.4 kHzOptimization is forRangevoice, and isconsistent withexisting Legacyvoice systems.Audio Level−10dBmOOptimization is forvoice, and isconsistent withLegacy voicesystems.Audio EncodingG.711 (8-bit pulseConsistent withcode modulationLegacy voice(“PCM”))systems.Video Resolution≧352x288 (SIF)Minimal acceptablesize for videoconferencing.Video Frame Rate≧20 frames perMinimalsecond (fps)optimization fordetection of facialexpressiontransitions.Voice/Video<100 millisecondsA differentialIntramedia-(ms)delay greater thanIntermedia100ms between voiceDifferential Delay& video isnoticeablysignificant.Video EncodingH.261 & MotionH.261 meets WANPicture Expertsinteroperability,Group (“MPEG”)-1MPEG-1 is moreconsistent withdesktop trends andqualityrequirements.Intramedia Latency<100msThe delay of the TE(TE)itself for encodingand framingpurposes.User Data Rate≧64 kbpsMinimal acceptabledata bandwidth fordata sharingapplications.Consistent withISDN Basic RateInstrument (“BRI”).Data EncodingHigh-level DataConsistent withLink Controlisochronous service(“HDLC”)bearer channels.encapsulation
Network QoS parameter requirements consist of those parts of the system that are between two TE endpoints. This includes a portion of the TE itself, the private network (if required) and the public network (if required). Some of the requirements imposed upon the network QoS are a result of the terminal QoS parameters. The following Table II summarizes the network QoS requirements.
TABLE IINetwork QoS ParametersParameter TypeParameter ValueParameter ExplanationIntramedia Latency<50 msIntramedia latency is(NE)the delay betweensource TE transmis-sion and destinationTE reception; i.e.the delay of NE.Network Capacity≧1,536 kbpsG.711 Audio (64kbps), MPEG-1 Video(1,344 kbps), HDLCdata (128 kbps).
The system QoS encompasses the terminal and network elements. The particular value critical to the system is the intramedia latency. The following Table III summarizes this value that is the sum of the terminal and network values for the same parameter.
TABLE IIISystem QoS ParametersParameter TypeParameter ValueParameter ExplanationIntramedia Latency<150 msIntramedia latency is(System)the delay betweensource transmissionand destinationreception. Itincludes latencyimposed by the sourceand destination TEsas well as the NE.These latency valuesmight includeencoding and decodingdelays, transmissiondelays and adaptationdelays.
The system QoS parameter of Intramedia Latency is the sum of twice the TE and the NE latency. Intramedia Latency parameter value is bounded by voice requirements since latent delay is more readily perceived by the ear than the eye. However, the delay itself is typically a function of video since it is the component requiring the most time for encoding and decoding.
Availability (“up-time”) includes several aspects. In particular, the network elements have very strict requirements. These requirements are typical of private branch exchanges (“PBXs”) and other private network voice equipment, but are very atypical of Legacy LANs. Most LANs are susceptible to power-losses, single points of failure and errant TE. An interactive multimedia system must closely follow the availability requirements of the legacy voice systems. The following Table IV summarizes Availability QoS parameters.
TABLE IVAvailability QoS ParametersParameter TypeParameter ValueParameter ExplanationTE Power5 watts (W) ofThis powerRequirementsphantom power (48requirement isvolts (V))consistent with theISDN BRI requirementsand will allow theleast commondenominator of voiceto function.NE PowerUninterruptableNE must be UPSRequirementspower supplycapable including(“UPS”)private NE.Single point of12 UsersNo more than 12 usersfailureshould be impacted bya single point offailure.Error Free Seconds>99.9%Meets requirement ofRatio (“EFS”)random bit error rateof 10−6.
The availability requirements are defined solely within the context of the private network. Additional availability parameters are discussed in G.821. See also, MMCF Working Document “Architecture and Network QOS”, ARCH/QOS/94-001, Rev. 1.7, Multimedia Communications Forum, Inc., (September 1994) and TR-TSY-000499, Transport Systems Generic Requirements (TSGR) Common Requirements, Bellcore Technical Reference, Issue 3, (December 1989).
The second of the fundamental integration issues is network services. Network services include transport services, connection management and feature management. Multimedia communication involves the transmission of data having more varied characteristics than video, voice or data in isolation. Therefore, the manner in which the network transports and manages the flow of video, voice and data is critical to the efficiency, flexibility and overall effectiveness of the network.
Transport services can be categorized into three groups: 1) packet, 2) circuit and 3) cell. The following Table V summarizes different aspects of each of these transport services.
TABLE VTransport ServicesPacketCircuitCellTypicalEthernet ®,ISDN, T1AsynchronoustechnologyToken Ring ®,Transfer ModeFrame Relay ®,(“ATM”)etc.MediaPacket dataIsochronousPacket &optimizationdata (voice,isochronousvideo)dataTransportMulticast,Point-point,Point-point,optimizationshared mediumfull-duplex,full-duplex,operationslow-costhigh-speedswitchingswitchingOptimized data1500 bytes1 byte (voice)48 bytessize(Ethernet ®)Transport4.2%none11.3%Overhead(64 bytes none − IP)(6 bytes − AAL1)TransportSharedSwitchedSwitchedMethodologyRouteRoutingSignallingSignallingMethodology(circuit(virtualswitching)circuitswitching)TypicalWidespread.Widespread.Very fewDeploymentDeployed asDeployed asinstallations.LANboth publicTypicallynetwork anddeployed asprivate NEprivatebackbonenetwork
Interactive multimedia requires the usage of an isochronous network because of the QoS requirements for voice and video. While it is possible to construct a packet network with sufficient bandwidth, buffering and intelligence to accommodate synchronous traffic it is considered to be prohibitively expensive and unnecessary. Nevertheless, both the LAN, PBX and WAN require interoperability.
At some point it is expected that the entire private network infrastructure will employ ATM. This will transpire upon the occurrence of several events. First, WANs must adapt to support ATM Points-of-Presence (“POPs”). Second, the telephone must disappear from the premise (replaced by an ATM audio device). Third, packet-based LAN TE must become ATM TE. Fourth, phantom power must be supported to the ATM TE (for availability purposes) Fifth, an 8 kHz synchronous clock must be supported and managed by all ATM equipment. Finally, the price of ATM TE and NE must approach that of Ethernet®, ISDN and isoEthernet® equipment.
Regardless of the interim private network infrastructure, ATM is the only backbone solution for the private network. It is the only scalable switching architecture that can transport packet and isochronous data. Furthermore, because it is deployed as a backbone, the aforementioned issues do not apply.
Connection management is the process employed by the private and public network routing functions. Because packet routing is a well established and defined process, it is not discussed further. Connection management within the confines of an isochronous network for interactive multimedia is a newer technology (albeit with old roots) and deserves discussion.
Signalling for circuit and cell switching is best defined by the ISDN signalling standards (see, TR-NWT-000938, Network Transmission Interface and Performance Specification Supporting Integrated Digital Services Network (ISDN), Bellcore Technical Reference, Issue 1, (August 1990)), isoEthernet® signalling (see, IEEE Proposed Standard 802.9a, “Isochronous services with Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Media Access Control (MAC) service”, (December 1994)) and ATM signalling (see, ATM Forum, “ATM User-Network Interface Specification—Version 3.0”, (September 1993) and ITU-T Recommendation Q.293×, “Generic Concepts for the Support of Multipoint and Multiconnection Calls”; (1993)). Historically, isochronous networks carry the signalling channel as an isochronous channel. Nevertheless, the signalling function can be shown to be better suited to a packet channel. A hub-routing function is the ideal location to perform the bridging between an isochronous signalling channel and a packet signalling channel. The natural packet protocol choice for a signalling channel is an Internet Protocol (“IETF IP”). Available on most LAN networks, as well as global routing capability, IP greatly enhances the signalling requirement of interactive multimedia.
Feature management consists of the management of those features provided by the private and public network for interactivity purposes. The PBX is followed as a model for interactive multimedia features. The following Table VI summarizes some of the more common features.
TABLE VIFeature ManagementSystem ServicesUser ServicesMaintenanceAccount CodesBuzz StationAutomatic RestartAuthorization CodesCallbackConnection DetailRecordingAutomatic NumberCall ForwardDefaultIdentificationInstallationDirect InwardCall ParkClass of ServiceDialing (“DID”)Direct OutwardCall PickupHot ConfigurationDialing (“DOD”)Hunt GroupsCall WaitingMultimedia on holdDo NotDisturb/OverrideNetwork NumberingHold/ConsultationPlanHoldNumber Dial PlanLast Number RedialShared ResourceMultiple/SharedQueuingCall AppearancesSystem SpeedConferenceDialing(multiparty)Vacant NumberTransferIntercept
The third of the fundamental integration issues is interoperability. An interactive multimedia system by nature implies interoperability, because a multimedia network as envisioned is too large and far-flung to employ the equipment of only a single supplier. Therefore, standards must be established that allow equipment from different suppliers to interact smoothly. To this end, interoperability must extend to transport mechanisms, signalling and compression standards.
There are certain existing communication technologies that must be supported and others that are used. A truly interoperable interactive multimedia system should guarantee that the physical and logical interfaces of each component adheres to a standard. Prior to 1992, this would have been almost impossible. The present day affords the opportunity to evolve the proprietary telephony of the PBX and the proprietary video of the video conferencing systems into standards-based systems in the same manner that the data systems evolved from proprietary mainframes to the standards-based LAN systems of today. The following Table VII summarizes the required standards of interoperability.
TABLE VIIInteroperability StandardsSignallingCompressionTransport StandardsStandardsStandardsisoEthernet ® (IEEEISDN NI-2G.711, G.722802.9a)(Audio)ATMQSIGH.221 (Video)ISDNQ.2931MPEG-1 (Video)H.320 (Audiovisual)
In addition to the standards required for communications, there are other specifications relating to application programming interfaces for terminal and server control. These include Microsoft® Telephony Application Programming Interface (“TAPI®”), Novell® Telephony Service Application Programming Interface (“TSAPI®”) and Microsoft® Open DataBase Connectivity (“ODBC®”).
Having now set the stage with a discussion of general issues concerning multimedia systems, more specific design issues may now be discussed. The specific design issue of concern is the systemic architecture and network design to implement a truly interactive network-wide multimedia system.
In a traditional telephony environment, the interactivity between the controller and the telephone is defined as a slave-master-slave relationship. In PBX model systems, the PBX is the master or controller for the private operation at a user's premises, and thereby controls the communication system componentry within the user's premises down to the individual telephones or slaves. Consequently, the PBX has absolute control and manages all of the system resources including, but not limited to, call processing and system initialization and recovery. Thus, there is no sharing of resources between componentry in a PBX model system. The concentration of system resources at a central location results in an increasingly complex network as network size increases.
The slave-master-slave architecture of the telephony network is opposite the client-server network used in computer systems. The client-server model refers to a computing system that splits the workload between personal computers (“PCs”) and one or more larger computers on the network. In computerese, this is distributed computing, whereby some processing work is done by the client device and some processing work is done by the server device. To date, the client-server architecture has been relegated to computer networks.
Proceeding further into the telephony networks, the PBX is then connected with other PBXs to a central office. The central office is then connected to an interexchange network with trunk-side connections to a higher class office. The hierarchal architecture of the telephony network employs the slave-master-slave relationship throughout. For instance, the central office acts as a master for multiple PBXs, or slaves, within its network. A centralized system, as such, affords operational benefits including the capability to diagnose network trouble, obtain meaningful information, and take corrective measures in a short period of time. However, slave-master-slave networks tend to be very complex to design, implement and maintain.
Furthermore, in systems employing a slave-master-slave architecture, the predominant point of failure is concentrated at the master. For instance, if a PBX handling an automated office, integrating both the voice and data communication in a single system, malfunctions, then the office will suffer an entire network communications black-out. Generally, there are contingency plans associated with such centralized networks to accommodate for a failure. However, the slave-master-slave architecture of typical telephony systems fundamentally suffers because of the lack of distributed and system-wide shared resources, thereby leading to the survivability of the entire system being committed to a single point of failure.
As previously mentioned, the process of system initialization and recovery is controlled by and managed through a central processor in a PBX model system. While this system provides for orderly sequencing of the initialization and recovery system, the system has several drawbacks. First, the operation of the network is dependent upon the central processing engine. Therefore, whole sections of the network may be “down” until the central processor has initialized and recovered the affected section. In a telephony network this is of no moment because full functionality is dependant upon the master. However, in an fully interactive multimedia system where separate channels (e.g. isochronous verses non-isochronous) handle disparate tasks, full telephony functionality is not required for the operation of, for example, a packet-based signalling network.
Secondly, centralized initialization and recovery systems assume a slave-master-slave architecture as opposed to a decentralized architecture. A decentralized architecture, such as a client-server relationship inherent in some computer networks, implicitly defines a loosely coupled relationship between the client and server. When the initialization and recovery system processes are centrally located, a tight coupling is necessarily implemented. For instance, if a transport interface card must be exchanged in a slave device, then a corresponding change in the central processor must also be effected. This inflexibility leads to a scalability concern as the communication network becomes larger and more feature rich.
Similar in nature to system initialization and recovery, the call processing function is performed by a central processing engine in the PBX model system. For instance, if a telephone on PBX I wishes to communicate across the public network to a telephone on PBX II, the call processing function is centrally controlled by PBX I, then by the central office equipment and finally by PBX II. The call processing function is passed along without any collaboration between successive controllers. Stated another way, there are on-going instructions from PBX I to the public network central offices, from the public network central offices to PBX II and from PBX II to the second telephone. In one respect this process seems simple, but the result is that the network is very complex because there is no cooperation between controllers. The telephony network is a system of commands, rather than a cooperation between distributed componentry.
In connection with systemic architecture, there are several ways to construct a database system for networks. In the telephony environment, PBX systems have utilized a single database since they are centrally controlled. This system is advantageous for a couple of reasons, namely, easy access to information and simplicity of database management. Distributed multiple databases have found a home in computer networks whereby processing may be distributed over multiple sites. Obviously, such systems are appropriate when sets of computers are assigned discrete tasks within a LAN, or WAN. In an interactive multimedia network, a centralized network of databases is of concern because of survivability issues, and a distributed network of databases is not acceptable due to database access speed problems.
In addition to systemic architecture, there are other topics related to network design, including call numbering plans and data routing systems, that are critical to communication systems. With respect to call numbering plans, every telephone line in the United States has a unique 10-digit address, comprising three divisions. The first division is a three-digit area code, commonly referred to a numbering plan area. Within the area, each central office is assigned at least one three-digit central office code. Within each central office, each customer has a line number between 0000 and 9999. Each central office code, therefore, can support 10,000 lines. In larger cities, it is common for a single switching system to serve multiple central office codes. Worldwide dialing is accommodated through an international direct dialing access code, a country code and the terminating telephone number.
The traditional telephony numbering plan requires interpretation of complex rules of hard-coded digit strings.
Modifications to the national or international dialing plans, or to network access codes requires engineers to rewrite digit analysis code. Since accommodating the complex national and international dialing plans makes digit analysis code complex, many PBX manufacturers require their users to configure fixed-length directory numbers. This complex and inflexible numbering plan system is not optimal for an interactive multimedia network.
On the issue of routing information through a network, there are methods of transferring information between PBXs in a telephony environment and methods inherent to routing data between nodes in a LAN. Traditionally, PBX technology has dealt with the transmission of synchronous communications on dedicated isochronous channels. PBX switching functions are normally determined manually by user configurations. Without a large number of nodes in a complex topology, PBXs have not been asked to transmit voice data through a large number of nodes in a highly distributed network.
Conversely, LAN technology has dealt with the transmission of asynchronous data over a non-isochronous medium in a distributed network. Routing in an asynchronous LAN must account for variations in transmission times when selecting a path between nodes in the network. Typically, this results in a solution where multiple packets traverse multiple routes to the final destination and the first arriving packet establishes the fastest route as designated by the routing algorithm. Traditionally, the fastest path routing of the LANs has had no application in the telephony environment.
Accordingly, what is needed in the art to provide a communications network wherein processing, storage and network resources are distributed among subsystems and hubs of the network, allowing the network to be scalable, fault tolerant and flexible.